Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-118.txt

Text File | 1994-12-08 | 45.3 KB | 1,165 lines | [TEXT/R*ch]

C.S.M.P. Digest             Sat, 20 Jun 92       Volume 1 : Issue 118

Today's Topics:

    Temporary ALERTS with THINK C ?
    ADA and CASE for Mac
    ETO only for the rich and wealthy ?
    Turning on 'Scroll lock' light on EX Keyboard
    Where's the volume icon?
    Think C problem
    Converting MPW C source to Think C source.
    Creating a Dialog in ViewEdit
    How do you get SuperDrive to kick into MFM mode?


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

Subject: Temporary ALERTS with THINK C ?
From: [e-mail]
Date: 10 May 92 14:53:24 +0200
Organization: University of Geneva, Switzerland

Hi !
I'm actually writing a little application to automaticaly shut down my Mac
at a given time.

I write warning messages 15, 5 and 1 minutes before shutting down.
The problem is that I want the warning message to appear as the very top
window on screen, even if my application is running in background (Sys 7 or
Multifinder).

I know I can use alerts to obtain the same result, but I don't want, because
ALERTS need the user to click the OK button. I just would like to display the
warning for 10 seconds and then erase it. Even if I'm working in another
application such as Word...

I tried "BringToFront" but it only brings it to the front of the application
process (behind the actual application window).

So:
1) How can I display a window at the very top without using ALERTS ?
2) If alerts must be used, is there a way to make them temporary whithout
   requiring the user intervention ?


Thanks for any help !

Sincerely,

Steve Jordi

+-------------------------+----------------------------------------------+
| Dpt of Geophysics       | Fax: + 41 22 320-5732                        |
| University of Geneva    |                                              |
| 13, Rue des Maraichers  | E-Mail: Internet:   [e-mail]      |
| 1211 GENEVA 4           |         Bitnet:     [e-mail]    |
| Switzerland             |         Compuserve: 70143,3056 (once a week) |
+-------------------------+----------------------------------------------+


+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 14 May 92 04:41:40 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.unige.ch> [e-mail] writes:

   The problem is that I want the warning message to appear as the very top
   window on screen, even if my application is running in background (Sys 7 or
   Multifinder).

To switch layers, test for the process manager using Gestalt.
IF it's implemented, do a GetCurrentProcess and SetFrontProcess
(OOH! NASTY ! You could also use AEInteractWithUser, even if
you're not processing an apple event)
IF IT'S NOT implemented, do a OpenDeskAcc ( CurApName ) which is a
skanky hack that doesn=t work under 7.0 but does under 6.x

   I tried "BringToFront" but it only brings it to the front of the application
   process (behind the actual application window).

You should use SelectWindow for that...
- --
h++ - new and improved !

"It's simple. Some people have braces in their names, and some don't. You'll
   just have to accept it the way it is." - Me: [e-mail]; Jon W{tte

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dorner)
Date: 14 May 92 18:19:01 GMT
Organization: University of Illinois at Urbana-Champaign

[e-mail] (Jon W{tte) writes:
>To switch layers, test for the process manager using Gestalt.
>IF it's implemented, do a GetCurrentProcess and SetFrontProcess

I've had considerable trouble with the Gestalt and the Process Manager
under A/UX 2.0.  Namely, Gestalt indicates it's available, but calls
to it crash.  So you have extra work to do if you want to be A/UX 2.0
compatible.
- --
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 18 May 92 19:38:46 GMT
Organization: MacDTS Mongols

In article <[e-mail]>,
[e-mail] (Steve Dorner) writes:
> [e-mail] (Jon W{tte) writes:
> >To switch layers, test for the process manager using Gestalt.
> >IF it's implemented, do a GetCurrentProcess and SetFrontProcess

> I've had considerable trouble with the Gestalt and the Process Manager
> under A/UX 2.0.  Namely, Gestalt indicates it's available, but calls
> to it crash.  So you have extra work to do if you want to be A/UX 2.0
> compatible.

That has to be a bug, the Process Manager is part of System 7, and those
features were rolled into A/UX in the 3.0 release.

Cheers,
kent

---------------------------

From: [e-mail] (Esa Eero Eklund)
Subject: ADA and CASE for Mac
Date: 12 May 92 08:47:07 GMT
Organization: Helsinki University of Technology, Finland


  I'm looking for ADA development system for Mac, possibly combined
with complete CASE environment, especially HOOD based CASE would be jam.
Do you have any recommendations?

  Howabout ALSYS ADA and MERIDAN ADA? Can they be integrated in MPW? And
where could I get some info on those products? What is your experience
on these products?

  Mighty thanks in advance!


Esa E Eklund 007E       !  Good morning, Dr. Chandra.
[e-mail]   !  This is Seagate ST277N.
ISU '90 student         !  I am ready for my first block test.
                        !  And the man cried.

+++++++++++++++++++++++++++

From: [e-mail] (Thad Humphries)
Date: 13 May 92 01:55:42 GMT


  EE> From: [e-mail] (Esa Eero Eklund) Newsgroups:
  EE> comp.sys.mac.programmer Organization: Helsinki University of
  EE> Technology, Finland
  EE>
  EE> I'm looking for ADA development system for Mac, possibly combined with
  EE> complete CASE environment, especially HOOD based CASE would be jam. Do
  EE> you have any recommendations?
  EE>
  EE> Howabout ALSYS ADA and MERIDAN ADA? Can they be integrated in MPW? And
  EE> where could I get some info on those products? What is your experience
  EE> on these
  EE> products?

This should be a FAQ 'cause I've answered it several times.  Here goes:

Only TeleSoft's Ada and Meridian's Ada run under the MacOS.  Both require MPW.
Alsys is for A/UX.  TeleSoft's product is $895 and I have not used it.  Meridian
is $495 ($149 students).  It's interfaces are about System 6.0.5 era with no
plans to support 7.  It's validated under MPW 3.0 but they will ship 3.2 if you
need it.  It does not support SADE and the Meridian debugger won't link with the
Mac libraries -- it is command line only, for text stuff in MPW.  Like all MPW
(and Ada) it is slow -- 80+ seconds to compile and link "hello world" on a IIci.
 Also, Meridian says you can't TASK with Quickdraw "because of a bug/features in
Quickdraw concerning its assumption about the placement of the stack pointer."
I haven't tried yet but plan to play with this soon.  Meridian tech support has
not responded to my messages on this issue, or when/if they will upgrade to
System 7.

I have written some Mac stuff in Ada, typical menu & window stuff plus off
screen bit maps, async sound.  Due to Ada's strict typing, it is agony.

Recommendation:  If you really need Ada on the Mac, think again and go for THINK
C or MPW C++.  If forced by a contract, by TeleSoft as it *has* to be better
(one would hope!).  If it is just for school, get Meridian at the $149 price and
sell it to someone when you graduate.

+++++++++++++++++++++++++++

From: [e-mail] (Brian Hanafee)
Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415)
Date: Fri, 15 May 1992 02:02:06 GMT


In article <[e-mail]> [e-mail] (Esa Eero Eklund) writes:
>  Howabout ALSYS ADA and MERIDAN ADA? Can they be integrated in MPW? And
>where could I get some info on those products? What is your experience
>on these products?

I don't know about Alsys Ada.  Meridian Ada does run under MPW; in
fact it both requires and comes with MPW.  I don't have enough
experience with it yet to comment.

Meridian Software Systems, Inc.
10 Pasteur St.
Irvine, CA 92718

[phone]
[phone]
Fax: [phone]

You may also be interested to know that Meridian was recently aquired
by another major player in the Ada market, Verdix.

- --
Brian Hanafee                         Advanced Decision Systems
[e-mail]                      1500 Plymouth Street
[phone]                        Mountain View, CA 94043-1230

+++++++++++++++++++++++++++

From: [e-mail] (Gary Morris @lone)
Date: 19 May 92 23:39:43 GMT
Organization: TeleSoft, San Diego, CA, USA

In <[e-mail]> [e-mail] (Thad Humphries) writes:

>  EE> From: [e-mail] (Esa Eero Eklund) Newsgroups:
>  EE>
>  EE> I'm looking for ADA development system for Mac, possibly combined with
>  EE> complete CASE environment, especially HOOD based CASE would be jam. Do
>  EE> you have any recommendations?

>Only TeleSoft's Ada and Meridian's Ada run under the MacOS.  Both require MPW.
>Alsys is for A/UX.  TeleSoft's product is $895 and I have not used it.

TeleSoft's Ada for the Macintosh only runs under AUX, not the MacOS.   And
thus, it doesn't work with MPW.  If you want to know more contact us.

- --GaryM
- --
Gary Morris                     Internet: [e-mail]
Ada Software Development        UUCP:     uunet!telesoft!garym
TeleSoft, San Diego, CA         Phone:    [phone]

---------------------------

From: [e-mail] (HP48SX Archive Maintainer)
Subject: ETO only for the rich and wealthy ?
Date: 16 May 92 14:26:49 GMT
Organization: Washington University in Saint Louis, Missouri USA

Hi,
I just got the new APDA catalog today, and I can see that they have
increased the price of ETO from $995 to $1295. I really hate this,
I was saving to upgrade my MPE C bvundle & C++ to the full E.T.O., and
now this very high change in price.  They still got a 1 month special
offer, $995 for the complete package, but then I can't get any credits
for mu old packages.  I almost had the  money to buy it. And now this.

I guess I will buy one of the 3rd party C++ libraries instead. Quite a
few is currently being ported.

There is no reason why Apple should increase the price that much. the
30% price increase is equal toabout 20 years of price increases here
:-(.
- --
Povl H. Pedersen             [e-mail]
HP48sx archive maintainer

All Opinions (C) Copyright the Integalactic Thought Association

+++++++++++++++++++++++++++

From: [e-mail] (John Nagle)
Date: Sat, 16 May 92 18:32:22 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

[e-mail] (HP48SX Archive Maintainer) writes:

>Hi,
>I just got the new APDA catalog today, and I can see that they have
>increased the price of ETO from $995 to $1295. I really hate this,
>I was saving to upgrade my MPE C bvundle & C++ to the full E.T.O., and
>now this very high change in price.  They still got a 1 month special
>offer, $995 for the complete package, but then I can't get any credits
>for mu old packages.  I almost had the  money to buy it. And now this.

        I expect that a full set of development tools will cost $10,000 to
$20,000 by the year 2000.  This is consistent with the consolidation in
the software industry.  One vendor (Microsoft) has a quarter of the market.
Three vendors have half.  Eleven vendors have three-quarters.  Everybody
else is fighting it out for the remaining quarter.  The industry is
now dominated by the battle for shelf space in retail outlets, just like,
say, laundry detergents.

        The evangelism era is over.

                    John Nagle

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 18 May 92 19:37:24 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (John Nagle) writes:

>         I expect that a full set of development tools will cost $10,000 to
> $20,000 by the year 2000.  This is consistent with the consolidation in
> the software industry.  One vendor (Microsoft) has a quarter of the market.
> Three vendors have half.  Eleven vendors have three-quarters.  Everybody
> else is fighting it out for the remaining quarter.  The industry is
> now dominated by the battle for shelf space in retail outlets, just like,
> say, laundry detergents.

>         The evangelism era is over.

Actually, I don't think this is the case. Any small development tools vendors,
which could produce an incremental compiler/linker system, or even better,
a dynamic object language environment, will certainly have a nice market window.

This because more and more developers realize that the big sellers of future
will be extremely complex applications, with constraints handling,
ai-type user interaction, and in general we need to glue together fairly
complex libraries.

Another trend is back to the document model applications, where the end user
starts with a document, and uses tools for producing the final result (original
Lisa idea, and the current Works/ClarisWorks trend).

Whoever produces development environments, where even non-star-programmers
could create interesting applications, will certainly have a nice market. I'm
not talking about Visual Basic and similar half-crappy attempts :-).

My vision is that it should be as easy to piece together an interesting
application as to jam on a guitar. The guitar has 24 frets and 6 strings,
but anyone with a musical talent will learn to play it within a month.

Cheers,
Kent
PS: Private comments.

---------------------------

From: [e-mail] (Eric A. Fisch)
Subject: Turning on 'Scroll lock' light on EX Keyboard
Date: 17 May 1992 09:28:23 -0500
Organization: U Texas Dept of Computer Sciences, Austin TX

I am interested in being able to illuminate the scroll lock light
on an Extended keyboard. I will be using THINK C. Is it also
possible to illuminate the num lock nd cpas lock lights without
the user pressing their appropriate keys??

regards,
Eric Fisch
[e-mail]



+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 18 May 92 00:39:39 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Eric A. Fisch) writes:
>
> I am interested in being able to illuminate the scroll lock light
> on an Extended keyboard. I will be using THINK C. Is it also
> possible to illuminate the num lock nd cpas lock lights without
> the user pressing their appropriate keys??

Check out the LED snippet in the snippets directory of ftp.apple.com or on
the Developer CDs.

You can do everything you want.  You just have to code it.  ;)

Jon

---------------------------

From: [e-mail]
Subject: Where's the volume icon?
Date: 15 May 92 15:47:55 GMT
Organization: Texas Instruments

Given the vRefNum for a volume, I need to find and copy the icon (ICN# and
ics#) for the volume.  Where is this information stored?  I've looked through
IM IV and VI and poked around with ResEdit, but haven't had any luck.  Any
pointers on where to look?

Thanks,
Mike Babin
Texas Instruments
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Chris Wysocki)
Date: 15 May 92 17:26:02 GMT
Organization: Harvard University, Cambridge, MA

In article <[e-mail]>, [e-mail] writes:
>
> Given the vRefNum for a volume, I need to find and copy the icon (ICN# and
> ics#) for the volume.  Where is this information stored?  I've looked through
> IM IV and VI and poked around with ResEdit, but haven't had any luck.  Any
> pointers on where to look?

You need to make a Control call to the disk driver to get the volume icon:

    Handle          iconH;
    HParamBlockRec  hpb;
    ParamBlockRec   pb;

    hpb.volumeParam.ioNamePtr = NULL;
    hpb.volumeParam.ioVRefNum = vRefNum;
    hpb.volumeParam.ioVolIndex = 0;
    FailOSErr(PBHGetVInfoSync(&hpb));

    pb.cntrlParam.ioVRefNum = hpb.volumeParam.ioVDrvInfo;
    pb.cntrlParam.ioCRefNum = hpb.volumeParam.ioVDRefNum;
    pb.cntrlParam.csCode = 21;
    if (PBControlSync(&pb) == noErr)
        FailOSErr(PtrToHand(*(Ptr *) pb.cntrlParam.csParam, &iconH, kLargeIconSize));

See IM IV-224 and V-470 for all the details.  As far as I know, there's no
way to get a small icon for a volume; you can only shrink down the large
icon.

Chris Wysocki
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Steve Christensen)
Date: 19 May 92 01:54:15 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] writes:

>Given the vRefNum for a volume, I need to find and copy the icon (ICN# and
>ics#) for the volume.  Where is this information stored?  I've looked through
>IM IV and VI and poked around with ResEdit, but haven't had any luck.  Any
>pointers on where to look?

Yep, it's in the driver for the disk the volume resides on.  Here's what to
do:

Ptr GetVolumeIcon(short theVRefNum) {
HVolumeParam    vpb;
CntrlParam    cpb;
long        *diskIcon;

vpb.ioNamePtr = nil;                // don't care about the name
vpb.ioVRefNum = theVRefNum;            // which volume
vpb.ioVolIndex = 0;                // just use vRefNum
if (! PBHGetVInfo((HParmBlkPtr) &vpb, false)) {
    cpb.ioVRefNum = vpb.ioVDrvInfo;        // drive number
    cpb.ioCRefNum = vpb.ioVDRefNum;        // driver refNum
    cpb.csCode = 22;            // "return media icon"
    if (! PBControl((ParmBlkPtr) &cpb, false)) {
        diskIcon = &cpb.csParam;    // a little type coercion
        return((Ptr) *diskIcon);    // return pointer to icon
    }
}
return(0);                    // error: return nil pointer
};

This will return the disk icon (i.e., a little floppy disk).  If you want
the drive icon (i.e., shows a Mac with an arrow pointing to the drive),
change the csCode value to 21.  The returned pointer will point to a structure
that has the same format as an ICN# resource (32 longs of icon data, followed
by 32 longs of icon mask).

steve
- --
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Steve Christensen            Never hit a man with glasses.
  [e-mail]            Hit him with a baseball bat.

---------------------------

From: [e-mail] (John Lindal)
Subject: Think C problem
Date: 13 May 92 17:04:42 GMT
Organization: California Institute of Technology, Pasadena

I am working with the Think C compiler and am having some problems.
I would appreciate if anyone could solve the following question:

I create a class (CThing1, say) that is a descendant of CObject.
Then I create a subclass of CThing1 (CThing2, say).

To initialize a new CThing2 object, I call its initialization routine.
This routine first calls CThing1's init and then changes a couple of
instance variables to fit CThing2.  The code looks like:

void CThing2::IThing2(void)
{
  inherited::IThing1(void);

  var1=[a new value]; var2=[a new value];
}

What actually happens, however, is that another variable (var3) ALSO gets
changed, even though IThing1() set it correctly.

That is:  I print out the values of var1,var2,var3 immediately after calling
IThing1() and they are correct.  I print out the values of var1,var2,var3
immediately after setting var1 and var2 AND ALL 3 HAVE CHANGED!!


Thanks for any help or suggestions.  John Lindal

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Date: 14 May 92 15:08:06 GMT
Organization: The World Public Access UNIX, Brookline, MA

John -

You may want to step through your code with the THINK C Debugger and see
exactly when var3 is being changed. This might help to shed some light on
your problem.

- --
- -- joe zobkiw                             Internet: [e-mail]
- --                                             AOL: AFL Zobkiw
- -- mac.synthesis.MIDI.THINK C.OOP.asm          CI$: 70712,515
- -- communications.networks.cool tunes...

+++++++++++++++++++++++++++

From: [e-mail] (Scott Bronson)
Date: 16 May 92 22:05:58 GMT

I just spent some time tracking down a bug that sounds related to this.
Basically, some instance variables were getting trounced that weren't
even touched by the method.  I finally buggered the culprit by
checksumming the problem variables with TMON.

The moral--always pass a long integer to StringToNum.  And, don't forget
how powerful checksum can be.

    - Scott

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 17 May 92 11:20:36 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

@mcl.mcl.ucsb.edu (Scott Bronson) writes:

   I just spent some time tracking down a bug that sounds related to this.
   Basically, some instance variables were getting trounced that weren't
   even touched by the method.  I finally buggered the culprit by
   checksumming the problem variables with TMON.

   The moral--always pass a long integer to StringToNum.  And, don't forget
   how powerful checksum can be.

No, here's the moral:

    Always have Strict Prototyping
    Always re-compile MacHeaders with SimplifyPrototypes 0

or

    Always compile with max warnings, and care about them !

- --
h++ - new and improved !

"It's simple. Some people have braces in their names, and some don't. You'll
   just have to accept it the way it is." - Me: [e-mail]; Jon W{tte

+++++++++++++++++++++++++++

From: [e-mail] (John Lindal)
Date: 18 May 92 22:05:15 GMT
Organization: California Institute of Technology, Pasadena

Well, the moral to my story (original post) is that dimensioning an array
as long array[4] allows me to only access array[0] to array[3].

Thanks to those who responded.  John Lindal

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 17 May 92 22:44:12 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail]
(Jon W{tte) writes:
>
>     Always have Strict Prototyping
>     Always re-compile MacHeaders with SimplifyPrototypes 0

Yes, that was one of the things I also learned during the DTS debugging
lab sessions, weird problems disappeared with strict prototype checking
turned on, so missing header files were flagged for insertion. This should be
the
default setting in Think C, IMHO.

> "It's simple. Some people have braces in their names, and some don't. You'll
>    just have to accept it the way it is." - Me: [e-mail]; Jon W{tte

I would like to thank my grand-grand-grand-father who settled by a lake bay with
a lot of sand and took a surname which didn't have any braces in ASCII-7
(Sandvik),
same with my mother and father who avoided any Swedish first names with braces.

Cheers,
Kent

---------------------------

From: [e-mail] (Tommy Nordgren)
Subject: Converting MPW C source to Think C source.
Date: 17 May 92 14:45:13 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

any hints on how to convert the code so it can be compiled under Think C.
    Tommy Nordgren.

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dakin)
Date: 18 May 92 17:48:26 GMT
Organization: Oceania Health Care Systems

In article <[e-mail]> [e-mail] (Tommy Nordgren)
writes:
> any hints on how to convert the code so it can be compiled under Think C.
>     Tommy Nordgren.

I use both MPW C and THINK C but haven't done any extensive converting from one
to the other.  I know that THINK's object stuff is not compatible with MPW
(yeah, I know, that was a tough one).  As for going from MPW to THINK - as far
as I know, the latest version of each uses the same header files (a big step in
the right direction), so that part should be relatively painless.  As for
inconsistencies, the only one I know of is the way quickdraw globals are
handled.  In THINK, you just use the global variable as is, in MPW, you must
put 'qd.' in front of it.  For example, accessing the current port looks like:

In THINK:  thePort...
In MPW:    qd.thePort...

Anyone else know of other differences?

Steve
- --
    Steve Dakin                        Oceania Health Care Systems
 [e-mail] (NeXT mail)         Palo Alto, CA [phone]
 [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Dennis Cohen)
Date: 19 May 92 14:01:45 GMT
Organization: Claris Corporation, Santa Clara CA

[e-mail] (Steve Dakin) writes:

>In article <[e-mail]> [e-mail] (Tommy Nordgren)
>writes:
>> any hints on how to convert the code so it can be compiled under Think C.
>>     Tommy Nordgren.

>I use both MPW C and THINK C but haven't done any extensive converting from one
>to the other.  I know that THINK's object stuff is not compatible with MPW
>(yeah, I know, that was a tough one).  As for going from MPW to THINK - as far
>as I know, the latest version of each uses the same header files (a big step in
>the right direction), so that part should be relatively painless.  As for
>inconsistencies, the only one I know of is the way quickdraw globals are
>handled.  In THINK, you just use the global variable as is, in MPW, you must
>put 'qd.' in front of it.  For example, accessing the current port looks like:

>In THINK:  thePort...
>In MPW:    qd.thePort...

>Anyone else know of other differences?

In THINK, integers are 16 bit unless otherwise set in preferences, in MPW they
are always 32-bit.  This also makes a difference in how things are pushed
on the stack.  Alignment within structs can also be different.  Any other
differences tend to fall into the arena of OO extensions.

- --
Dennis Cohen
Claris Corp.
 ****************************************************
Disclaimer:  Any opinions expressed above are _MINE_!

+++++++++++++++++++++++++++

From: [e-mail] (Paul Potts)
Date: 19 May 92 17:40:25 GMT
Organization: Instructional Technology Laboratory, University of Michigan

In article <[e-mail]> [e-mail] writes:
>In article <[e-mail]> [e-mail] (Tommy Nordgren)
>writes:
>> any hints on how to convert the code so it can be compiled under Think C.
>>     Tommy Nordgren.
>
>I use both MPW C and THINK C but haven't done any extensive converting from one
>to the other.  I know that THINK's object stuff is not compatible with MPW
>(yeah, I know, that was a tough one).  As for going from MPW to THINK - as far
>as I know, the latest version of each uses the same header files (a big step in
>the right direction), so that part should be relatively painless.

I've had great success converting recent code easily from one to the other
with no modifications. THINK has greatly improved compatibility and 99.99%
of our code required no modifications.

The only difference that we found is that THINK is an ANSI compiler and
MPW isn't, or, at least it doesn't complain about some ANSI violations.
The one construct that caused problems was a use of the question-mark
operator that needed to be parenthesized differently. If you are writing
ANSI C under MPW that shouldn't be an issue.


- --
"breakpoints" _See_also_ debugging, watch expressions; "debugging breakpoints"
 _See_ breakpoints; "debugging watch expressions" _See_ watch expressions;
"watch expressions" _See_also_ debugging... (Borland C++ manual index)
Paul R. Potts, Software Designer --- [e-mail] <--- me!

---------------------------

From: [e-mail] (John Gray)
Subject: Creating a Dialog in ViewEdit
Organization: AI duPont Inst.
Date: Thu, 30 Apr 1992 18:49:17 GMT

I'm fairly new to the Mac and MacApp and I am having problems creating
a simple modal dialog box using ViewEdit to create the view template.

The dialog is simple. It has a label, a field to enter a number, a Ok button
and a Cancel button.  When I run the thing I get a labels (not even
the OK and Cancel labels in the buttons).  Clicking on with button highlights
the button but does nothing else.  Clicking in the number field crashes
the Mac.  At this point I would be happy to starting a dialog with just
the button which works correctly (With labels and functionality).

I have been through the manuals to no avail.  I have successful created the
main view for the application as indicated in the MapApp C++ Tutorial.

I am using code from DialogDemos demo from MacApp 3.0 to bring up the dialog.

    FailNIL(aWindow = gViewServer->NewTemplateWindow((short)kThresDLogId, NULL));
    dismisser = aWindow->PoseModally();
    if (dismisser == 'ok  ')
        n = ((TNumberText *)(aWindow->FindSubView('numb')))->GetValue();
    else
        n = 0;
    aWindow->Close();

Any suggestions?

Thanks
John Gray
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Shigeo Suwa)
Date: 1 May 92 05:15:03 GMT
Organization: Nomura Research Institute, Ltd.

In article <[e-mail]> [e-mail] (John Gray) writes:

>The dialog is simple. It has a label, a field to enter a number, a Ok button
>and a Cancel button.  When I run the thing I get a labels (not even
>the OK and Cancel labels in the buttons).  Clicking on with button highlights
>the button but does nothing else.  Clicking in the number field crashes
>the Mac.  At this point I would be happy to starting a dialog with just
>the button which works correctly (With labels and functionality).
>
>Any suggestions?

Did you include "Dialog.rsrc" in your own "YourApp.r" file?

If you didn't make your own "YourApp.r" file, the default one (located
"...MacApp 3.0:Interfaces:RIncludes:Default.r") is used.  In "Default.r",
the include statement for "Dialog.rsrc" is commented out.

You must make your own "YourApp.r" and include "Dialog.rsrc".

- --
Shigeo Suwa ([e-mail])
MIX:ssuwa   CompuServe:74100,350   NIFTY:PBA00350

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 17 May 92 23:00:43 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Shigeo Suwa) writes:
>
> In article <[e-mail]> [e-mail] (John
Gray) writes:
>
> >The dialog is simple. It has a label, a field to enter a number, a Ok button
> >and a Cancel button.  When I run the thing I get a labels (not even
> >the OK and Cancel labels in the buttons).  Clicking on with button highlights
> >the button but does nothing else.  Clicking in the number field crashes
> >the Mac.  At this point I would be happy to starting a dialog with just
> >the button which works correctly (With labels and functionality).
> >
> >Any suggestions?
>
> Did you include "Dialog.rsrc" in your own "YourApp.r" file?
>
> If you didn't make your own "YourApp.r" file, the default one (located
> "...MacApp 3.0:Interfaces:RIncludes:Default.r") is used.  In "Default.r",
> the include statement for "Dialog.rsrc" is commented out.
>
> You must make your own "YourApp.r" and include "Dialog.rsrc".

The only sore thing with this trick is that Rez can't resolve resources
with the same ID, something which happens if you use the same resource
editor for creation of different .rsrc files. For instance STR
resource IDs usually start from the same ID base, and by inclusion of
various .rsrc you get nice errors. This is the reason I usually operate
with only one .rsrc file.

BTW, at the latest BAMADA meeting a new View editor was shown, called AdLib.
It handles MacApp 3.0 Views, adorners, behaviors, drawing environments,
the window/view is always in run mode, and you just add and change elements
as in a drawing package. The application was done by a consultant who wanted
to learn MacApp (I guess it shows the level of training programs one could do
in an object framework :-)). Stay tune for more information abou this really
nice product.

Cheers,
Kent

---------------------------

From: [e-mail] (Steve Berkley)
Subject: How do you get SuperDrive to kick into MFM mode?
Date: 24 Apr 92 19:31:02 GMT
Organization: University of Rochester - Rochester, New York

In the continuing epic to get a simple disk imaging program going,
I need one last, *vital* piece of information: What do I do to get
the disk driver to kick into MFM mode on the SuperDrive?  Also,
how can I test for presence of the SuperDrive?  I'm using PBRead
to read direct sectors off the disk, and need to read sectors 0-9
off the diskette (like an IBM disk), not the usual 8-12 sectors
scheme used on 800K and 400K floppies...

Any hints, tips, would be appreciated.  Or references to tech-notes
that discuss this.

Thanks in advance,
Steve Berkley
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Steve Christensen)
Date: 5 May 92 01:51:16 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Steve Berkley) writes:

>In the continuing epic to get a simple disk imaging program going,
>I need one last, *vital* piece of information: What do I do to get
>the disk driver to kick into MFM mode on the SuperDrive?  Also,
>how can I test for presence of the SuperDrive?  I'm using PBRead
>to read direct sectors off the disk, and need to read sectors 0-9
>off the diskette (like an IBM disk), not the usual 8-12 sectors
>scheme used on 800K and 400K floppies...

The floppy disk driver will switch the drive into MFM mode ONLY when it sees
an MFM disk in the drive (for non-HD disks), or if an HD disk is currently
inserted.  There is no programatic way to force it into that mode.

As far as testing for the presence of a SuperDrive, this is probably not
what you really need to do.  I assume you just want to know what kind of
disk you've got.  You can find this out by making a Format List status call
(csCode=6) to the driver and looking up the current format...

steve

- --
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Steve Christensen            Never hit a man with glasses.
  [e-mail]            Hit him with a baseball bat.

+++++++++++++++++++++++++++

From: [e-mail] (Terje Finstad)
Date: 7 May 92 15:48:56 GMT
Organization: Dept. Physics

In article <[e-mail]>, [e-mail] (Steve Christensen) writes:
>
> [e-mail] (Steve Berkley) writes:
>
> >In the continuing epic to get a simple disk imaging program going,
> >I need one last, *vital* piece of information: What do I do to get
> >the disk driver to kick into MFM mode on the SuperDrive?  Also,
> >how can I test for presence of the SuperDrive?  I'm using PBRead
> >to read direct sectors off the disk, and need to read sectors 0-9
> >off the diskette (like an IBM disk), not the usual 8-12 sectors
> >scheme used on 800K and 400K floppies...
>
When I try the same thing ( not necessarily exactly the same way, but )
I can read sector 1 to 9 ( as on IBM ) even though the diskette is formatted
with ten sectors pr track. The .sony driver always skips sector 0 (zero)
This means every tenth block will be inacessible. The .sony driver thinks he
is shewing on a MS-DOS formatted 720 K MFM diskette. As stated by mr.
Christensen:
>
> The floppy disk driver will switch the drive into MFM mode ONLY when it sees
> an MFM disk in the drive (for non-HD disks), or if an HD disk is currently
> inserted.  There is no programatic way to force it into that mode.
>
"no programmatic way"  hm.. ...under *normal circumstances? or always?.
Thinking aload: does this also mean that the driver uses fixed
hardcoded parameters in ROM to a large extent. I think that by pulling the
diskette driver aport-code wise-, you may find a way for it to handle
800 K MFM diskettes, since you are "so close".
In the process you may also find an effective way of shredding (spelling ?)
MS-DOS or other diskettes.
Mr. Christensen's statement above seems to imply that there is  no way one
can format a 720 K diskette on the SuperDrive, and therefore definitely not
a 800 K MFM diskettes.  That may be.  I have no reasons to not believe him.
His statement is not exactly as I interpreteded it either.
Well I'm building up to stating something I hope will not be taken in a
negative way. I can see many reasons for discouraging floppy drive hacking...
many to protect the hackers but also those that might use nonstandard floppy
manipulation as part of their copy protection scheme.
But when you read his signature, you must think he is nice guy that is not
too worried.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   Steve Christensen            Never hit a man with glasses.
>   [e-mail]            Hit him with a baseball bat.
>
Is there any else 'out there' that can help shredding Steve Berkley's
diskettes?  There must be some people that have worked on this sort of thing.
Written articles about how to defeat copy protection schemes etc.?

( I have understood that Steve Berkley's project is not about this )

( those with the knowledge and paranoic fear for their diskette artistery
  could  give the guy a patch to put in some driver hooks,
  it's very unlikely these could be used for anything "harmful",
  It is more dangerous that he and others have to first understand how
  to defeat copyprotection, to be able to do a presumably simple task
  of setting the number of sectors pr. track, with or without the .sony
)

Sincerely Terje

===========[e-mail]======================================


+++++++++++++++++++++++++++

From: [e-mail] (Matthew T. Russotto)
Date: Thu, 07 May 92 17:44:35 GMT
Organization: College of Engineering, University of Maryland, College Park

In article <[e-mail]> [e-mail] (Terje Finstad) writes:

>When I try the same thing ( not necessarily exactly the same way, but )
>I can read sector 1 to 9 ( as on IBM ) even though the diskette is formatted
>with ten sectors pr track. The .sony driver always skips sector 0 (zero)
>This means every tenth block will be inacessible. The .sony driver thinks he
>is shewing on a MS-DOS formatted 720 K MFM diskette. As stated by mr.

>I think that by pulling the diskette driver aport-code wise-, you may
>find a way for it to handle
>800 K MFM diskettes, since you are "so close".

This seems likely.  What I would guess is happening is that at some
level, the Sony driver has either a table or a method of calculating
track and sector from the block number.  Find this table/calculation,
modify it, and you are in business.

>Mr. Christensen's statement above seems to imply that there is  no way one
>can format a 720 K diskette on the SuperDrive
Not so, you can tell the .Sony driver to format a disk as 720K
MS-DOS-- you just can't force it to _read_ an arbitrary disk as MFM
rather than GCR.  But it sounds like that, at the lowest level, the
.Sony driver is already doing the right thing.

>Is there any else 'out there' that can help shredding Steve Berkley's
>diskettes?  There must be some people that have worked on this sort of thing.
>Written articles about how to defeat copy protection schemes etc.?

I remember this sort of fun from my Apple II days...

- --
Matthew T. Russotto    [e-mail]    [e-mail]
Some news readers expect "Disclaimer:" here.
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 8 May 92 19:01:03 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Terje Finstad) writes:
> Mr. Christensen's statement above seems to imply that there is  no way one
> can format a 720 K diskette on the SuperDrive, and therefore definitely not
> a 800 K MFM diskettes.

Remember that Apple File Exchange and DOS Mounter *will* let you create 720K
MFM DOS-format disks. I have even created a 720K MFM Mac-format disk, just
to satisfy myself it could be done. The Disk Initialization package does
a Status call to the disk driver to get the list of available formats
(based on the fact that there's a DD disk in the drive, rather than an HD
disk); it then does a Control call to choose one of these. I just intercepted
the Control call with MacsBug, and changed the index that it passed.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00

+++++++++++++++++++++++++++

From: [e-mail] (Steve Christensen)
Date: 19 May 92 00:49:11 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Terje Finstad) writes:

>"no programmatic way"  hm.. ...under *normal circumstances? or always?.
>Thinking aload: does this also mean that the driver uses fixed
>hardcoded parameters in ROM to a large extent. I think that by pulling the
>diskette driver aport-code wise-, you may find a way for it to handle
>800 K MFM diskettes, since you are "so close".
>In the process you may also find an effective way of shredding (spelling ?)
>MS-DOS or other diskettes.

No, there is no programmatic way.  It may be possible to call into the middle
of the driver to get a bits and pieces, but that will typically involve
jumping into the middle of the ROM, and thus needing to keep track of the
ROM addresses of the appropriate routines.  Note that this will not work
in the case of the IIfx and Quadra 900 (because they use a separate processor
to run the SWIM chip and disk drives), or on portable Macs because of power
management issues.  Also, as floppy technologies progress, I would expect
Apple to use new chips and/or drives that aren't necessarily based on the
current batch of hardware, so anything that plays around that low-level
would stop working, crash, etc.

>Mr. Christensen's statement above seems to imply that there is  no way one
>can format a 720 K diskette on the SuperDrive, and therefore definitely not
>a 800 K MFM diskettes.  That may be.  I have no reasons to not believe him.

Not at all.  You can format any of the 4 supported disk formats (400K, 800K,
720K, 1440K) solely with driver calls as long as the appropriate disk
controller, drive, and media are there.  Tech Note #273 (I believe) goes into
detail on the floppy driver's control and status calls.  Making a "return
format list" call will list the current and possible formats for a particular
drive, then passing the format number (1..n) to the format call will format
the disk correctly.

But you're right about not being able to format an 800K _MFM_ disk.  That's
not one of the formats the floppy driver knows about.

steve
- --
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Steve Christensen            Never hit a man with glasses.
  [e-mail]            Hit him with a baseball bat.

+++++++++++++++++++++++++++

From: [e-mail] (Steve Christensen)
Date: 19 May 92 01:04:21 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Matthew T. Russotto) writes:
[e-mail] (Terje Finstad) writes:
>>I think that by pulling the diskette driver aport-code wise-, you may
>>find a way for it to handle 800 K MFM diskettes, since you are "so close".

>This seems likely.  What I would guess is happening is that at some
>level, the Sony driver has either a table or a method of calculating
>track and sector from the block number.  Find this table/calculation,
>modify it, and you are in business.

The Sony driver does a block number to track/side/sector calculation, but
the calculation is not table-driven, and is hard-coded to the 4 formats
supported by the driver.  Also, that particular routine is not vectored,
so short of replacing a good chunk of the driver, it's tough to get to.

>>Mr. Christensen's statement above seems to imply that there is  no way one
>>can format a 720 K diskette on the SuperDrive
>Not so, you can tell the .Sony driver to format a disk as 720K
>MS-DOS-- you just can't force it to _read_ an arbitrary disk as MFM
>rather than GCR.  But it sounds like that, at the lowest level, the
>.Sony driver is already doing the right thing.

[putting on my Apple hat] Hacking the floppy driver is a big no-no.  It won't
work on all Macs (differing hardware), and may crash on new Macs if they use
non-SWIM based hardware.  Bad! Bad! Bad!  [taking off my Apple hat]

steve
- --
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Steve Christensen            Never hit a man with glasses.
  [e-mail]            Hit him with a baseball bat.

---------------------------

End of C.S.M.P. Digest
**********************